Windows Server 2003 Maintenance Made Easy (Continued)

To simplify monitoring hundreds or thousands of generated events each day, the administrator should use the filtering mechanism provided in the Event Viewer or use one of the operational management packages mentioned earlier. Although warnings and errors should take priority, the informational events should be reviewed to track what was happening before the problem occurred. After the administrator reviews the informational events, he or she can then easily filter out the informational events and view only the warnings and errors.

The three event logs on all servers and the three extra logs on a DC can be archived manually, or a script can be written to automate the task. You should archive the event logs to a central location for ease of management and retrieval.

The specific amount of time to keep archived log files varies on a per-organization basis. For example, banks or other high-security organizations might be required to keep event logs up to a few years. As a best practice, organizations should keep event logs for at least three months.

The script logarchive.vbs (see Listing 1) can retrieve event logs and store them in a central location. The process might take a long time (up to a few hours) depending on the size of the log files as well as how many servers you're pulling from. Avoid running this script over slow WAN connections so that bandwidth is conserved.

Another file, logarchive.ini, is required when using logarchive.vbs. This file, shown next, contains a list of servers and the following archiving modes: T means purge after archiving; F means archive only.

To use logarchive.vbs, do the following:

1. Verify that the logarchivelog.vbs and logarchive.ini files are in a pathed directory.
2. Right-click the logarchive.ini file and type the list of servers on which you want to archive event logs.
3. Choose Start, Run and type cmd to open a command prompt.
4. At the command prompt, type cscript logarchive.vbs.

The command in step 4 archives all the event logs for the servers that were specified in the logarchive.ini file. The log files are stored in the directory specified in the script. Logs will be labeled in the following format:

servername_logname_date.log

For example, sfdc01_sec_02202004.log is the name for the SFDC01 server's Security log, archived on February 20, 2004. It is recommended that you label log files in the following manner:

• _sec_ Security log
• _app_ Application log
• _sys_ System log
• _rep_ File Replication log
• _dns_ DNS Server log
• _dir_ Directory Service log

Note that logarchive.vbs does not purge the event logs.

Weekly Tasks
Hardware components supported by Windows Server 2003 are reliable, but this doesn't mean that they'll always run continuously without failure. Hardware availability is measured in terms of mean time between failures (MTBF) and mean time to repair (MTTR). This includes downtime for both planned and unplanned events. These measurements provided by the manufacturer are good guidelines to follow; however, mechanical parts are bound to fail at one time or another. As a result, you need to monitor hardware weekly to ensure efficient operation.

You can monitor hardware many different ways. For example, server systems might have internal checks and logging functionality to warn against possible failure, Windows Server 2003's System Monitor might bring light to a hardware failure, and a physical hardware check can help to determine whether the system is about to experience a problem with the hardware.

If a failure has occurred or is about to occur, having an inventory of spare hardware can significantly improve the chances and timing of recoverability. Checking system hardware on a weekly basis provides the opportunity to correct the issue before it becomes a problem.

Disk space is a precious commodity. Although the disk capacity of a Windows Server 2003 system can be virtually endless, the amount of free space on all drives should be checked daily. Serious problems can occur if there isn't enough disk space, including, but not limited to, application failures, system crashes, unsuccessful backup jobs, service failures, and more. To prevent these problems from occurring, administrators should keep the amount of free space to at least 25 percent.